Programmable logic devices (PLDs) are a well-known type of digital integrated circuit that may be programmed by a user (e.g., a circuit designer) to perform specified logic functions. One type of PLD, the field-programmable gate array (FPGA), typically includes an array of configurable logic blocks (CLBs) that are programmably interconnected to each other and to programmable input/output blocks (IOBs). This collection of configurable logic may be customized by loading configuration data into internal configuration memory cells that define how the CLBS, interconnections, and IOBs are configured.
The ease with which a given logic function can be implemented using a PLD makes PLDs very inexpensive in small quantities. In contrast, application-specific integrated circuits (ASICs) are more expensive to implement a given design, but less expensive to produce in large quantities. Thus, where economies of scale warrant, a vendor may want to design and implement a logic circuit using a PLD, taking advantage of the ease of design and the attendant reduction in time to market. Then, if economies of scale warrant, the vendor may convert the PLD design into a design specification for another type of integrated circuit, such as a mask programmed integrated circuit (MPIC). This conversion process may be to a simple mask programmed version of the PLD, or a totally different representation.
FIG. 1 illustrates a system 100 in which a PLD 102 is removed from an IC site 104 and replaced with a new integrated circuit 106 having the same functionality as PLD 102. PLD 102 conventionally includes a collection of configurable elements 108 that are programmed to perform the functions of a circuit design 110. The new integrated circuit 106, a mask-programmable gate array, for example, includes design implementation logic 112 that also performs the functions of circuit design 110.
FIG. 2 illustrates a method of converting a PLD representation of circuit design 110 of FIG. 1 into a second representation for use with a different implementation technology (the “target technology”). Beginning with step 210, a user enters a text or graphic description of circuit design 110 using a software tool, such as the ViewDraw™ tool available from ViewLogic, Inc., of Milpitas, Calif. Next, in step 212, the software tool then creates a design description 214. Design description 214 may include, for example, a conventional hardware-description language (HDL) or netlist description of circuit design 110.
PLDs require custom circuit representations suited for use in specific PLD architectures. Data for implementing design 110 on a specific PLD is therefore generated at step 215. These data include a new netlist representation 217 of circuit design 110 and a bit-wise representation of circuit design 110, i.e., bitstream 218. Netlist 217 and bitstream 218 may be generated using, for example, the XACT™ software, version 5.0, provided by Xilinx, Inc., having an address at 2100 Logic Drive, San Jose, Calif.
Next, in step 220, the information for programming the group of configurable elements 108 in PLD 102 is parsed from netlist 217 and/or bitstream 218. The parsing step organizes the data in bitstream 218 to produce an element identifier 221 and element programs 225. Element identifier 221 uniquely identifies each programmable element in the new integrated circuit 106 and element programs 225 specifies the configuration of those programmable elements. For example, one set of bits from bitstream 218 programs a Configurable Logic Block (CLB) of an FPGA, another set of bits, from the same bitstream 118, identifies and programs an Input/Output Block (IOB) of the FPGA, while yet another set of bits configures the interconnections between the CLB and the IOB.
A pre-compile representation 237 of the PLD representation of circuit design 110 is built during step 230. Step 230 may include generating an HDL file that includes several instances of different general models. Each instance of a general model corresponds to a different type of configurable element in PLD 102. Element identifier 221 identifies the type of general model to use (e.g., an IOB general model, a CLB general model, or an interconnection element general model) for each programmable element in new integrated circuit 106. The corresponding element program 225 defines some parameters for the instance of the general model, e.g., which circuits to include in a given instance of a general model.
At step 240, a compiler converts the pre-compile representation 237 into a post-compile representation 247. The pre-compile representation 237 includes an accurate representation of circuit design 110 in PLD 102. However, pre-compile representation 237 also includes a number of unnecessary structures. For example, if a given instance of an input/output block general model is defined as an input port (the parameters to that instance define the instance as an input port), then the structures in that instance that implement output functions are not necessary. The compile step 240 removes the unnecessary structures. In one embodiment, the compiler is a Synopsys Design Compiler>, available from Synopsys, Inc., of Mountain View, Calif. The compiler uses the a fabrication technology library 242 for the target technology to generate the post-compile representation 247.
At step 250, a place and route tool is used to place and route the post-compile representation 247 in the target technology. An exemplary place and route tool is Gate Ensemble™ from Cadence Systems, Inc., of Santa Clara, Calif. Step 250 produces a specification for fabrication 255, typically a magnetic tape written in Caltech Intermediate Format (CIF, a public domain text format) or GDSII Stream (formerly also called Calma Stream, now Cadence Stream). At step 260, from the specification for fabrication 255, a semiconductor foundry manufactures the new integrated circuit 106 that functions as specified by circuit design 110.
For a detailed description of exemplary methods and apparatus for converting PLD circuit designs for use in other circuit technologies, see U.S. Pat. No. 5,815,405, entitled “Method and Apparatus for Converting a Programmable Logic Device Representation of a Circuit into a Second Representation of the Circuit,” by Glenn A. Baxter, issued Sep. 29, 1998, which is incorporated herein by reference.
The design engineer responsible for converting a PLD design for use with a target technology must verify the operation of the converted design to ensure that the new implementation is functionally equivalent to the PLD implementation. This is particularly important because the fabrication technology used to fabricate the new integrated circuit 106 affects the speed of the device. Thus, even though all of circuit design 110, as implemented in the PLD 102, is completely defined in design implementation logic 103, the speed of the new integrated circuit 106 may be significantly different than that of PLD 102. These speed differences may result in malfunctions because of race conditions and other timing-related problems.
FIG. 3 depicts a conventional clock tree 300 used to illustrate potential timing problems in converted designs. Clock tree 300 includes a net 310 that distributes a clock signal on terminal TCLK to a number of clock branches A-M. Each of clock branches A-M connects to one or more destination circuits, as indicated by the annotations provided for each clock branch. For example, clock branch E connects to 17 destination circuits.
One line from clock branch A and another line from clock branch D connect to the clock terminals of respective flip-flops 305 and 310, which are exemplary destination circuits. Ideally, clock signals provided on clock terminal CLK should arrive at the clock terminals of flip-flops 305 and 310 (and the other destination circuits) at approximately the same time. Otherwise, time-dependent data can be corrupted. For example, if flip-flop 310 clocks before flip-flop 305, then flip-flop 310 may capture data before that data is available from flip-flop 305, the result being that flip-flop 310 could contain incorrect data.
Ensuring that each destination circuit receives clock signals at approximately the same time is difficult because of the myriad combinations of paths that make up a typical clock tree. These paths include interconnected lines of different lengths and intervening components, therefore each path has some associated delay. The delays of the various signal paths within net 310 should therefore be balanced to ensure fast, error-free circuit operation.
The traditional method of balancing signal paths within a given circuit includes simulating circuit operation and monitoring the results at selected circuit nodes for errors. Such errors, combined with an understanding of the intended function of the circuit, enable test engineers to identify problem paths. Once the problem signal paths are located, the netlist is changed to alter the offending paths. For example, if a clock signal arrives too late to capture some data, either the clock signal or the data line can be rerouted to change the relative delays.
The trouble with the conventional approach is two fold. First, identifying problem paths by simulating circuit operation requires an intimate knowledge of the logic being implemented. A user must therefore understand the functionality of a given circuit to perform a conversion from one circuit technology to another. Second, each signal path of a given net may be related to others. Thus, rerouting a signal path to solve one problem can change the delays of many other paths, and thereby introduce new timing errors. The new errors must, in turn, be corrected, which can introduce still other timing errors. Balancing signal paths is therefore an iterative and often very time-consuming process. What is needed is a more efficient method of converting one representation of a circuit into another, preferably without requiring those responsible for the conversion to understand the function of the circuit.